Kubelet从人门到放弃：拓扑管理（上）

友情提示：全文4090多文字，预计阅读时间6分钟

摘要

《Kubelet从入门到放弃系列》将对Kubelet组件由Linux基础知识到源码进行深入梳理。上一篇zouyee带各位看了Kubelet从入门到放弃:识透CPU管理，其中提及拓扑管理，本文将对此进行深入剖析，拓扑管理在Kubernetes 1.18时提升为Beta。TopologyManager功能可实现CPU、内存和外围设备(例如SR-IOV和GPU)的NUMA对齐，从而满足低延迟需求。

一、背景介绍

       注：下文TopologyManager简称为拓扑管理器

       1.1 需求说明

随着单服务器节点内的处理器数量、硬件加速器及其他外围设备日益增多，越来越多的系统利用 CPU 和硬件加速器的组合来支持对延迟要求较高的任务和高吞吐量的并行计算。这类负载包括电信、科学计算、机器学习、金融服务和数据分析等。如何优化延迟敏感型的高性能并行计算应用的性能成了一个重大的挑战。在引入拓扑管理器之前，CPU、内存和设备管理器在资源分配决策上彼此独立。这可能导致在多处理系统上出现与期望不符的资源分配，由于这些与期望不一致的分配，对性能或延迟敏感的应用将受到影响，例如， CPU 和设备是从不同的 NUMA 节点分配的，因此会导致额外的延迟。为了获得最佳性能，需要与 CPU 分配、内存和设备局部性等进行亲和性有关的优化。拓扑管理器是Kubelet中ContainerManager组件的一部分，充当存储分配资源信息的角色，以便ContainerManager组件可以做出与拓扑结构相适应的资源分配决策，在资源分配的时候实现拓扑结构上的对齐。注意拓扑管理不是单独起作用的，它和CPU manager、memory manager、Device manager共同为Pod分配资源，优化资源访问。1.2 NUMA

        在CPU管理中，我们已经介绍了NUMA技术（再回顾一遍）。

NUMA，以内存访问的不一致性为代价，减轻对总线和memory的带宽需求。这种结构对进程调度算法的要求较高，尽量减少跨Node的内存访问次数，以提升系统性能。Core之间会共享总线、内存等资源。如果Core的数量较少，则没什么问题，但随着Core的增多，对总线以及内存带宽的需求就会显著增大，最终总线和内存会成为系统性能的瓶颈。

如图1所示，一个NUMA Node包括一个或者多个Socket，以及与之相连的local memory。一个多核的Socket有多个Core。如果CPU支持HT，OS还会把这个Core看成 2个Logical Processor。

图1 NUMA结构

以下为相关概念说明：

• Socket是一个物理上的概念，指的是主板上的cpu插槽

• Node是一个逻辑上的概念，上图中没有提及。由于SMP体系中各个CPU访问内存只能通过单一的通道，导致内存访问成为瓶颈，cpu再多也无用。后来引入了NUMA，通过划分node，每个node有本地RAM，这样node内访问RAM速度会非常快。但跨Node的RAM访问代价会相对高一点,我们用Node之间的距离（Distance，抽象的概念）来定义各个Node之间互访资源的开销。

• Core就是一个物理cpu,一个独立的硬件执行单元，比如寄存器，计算单元等

• Thread就是超线程（HyperThreading）的概念，是一个逻辑cpu，共享core上的执行单元

二、功能介绍

         2.1 相关配置

        注意：为了将 Pod 中的 CPU 与其他请求资源对齐，需要启用CPU 管理并且配置适当的 CPU 管理策略

        在Kubernetes  1.18版本之前若需要启用拓扑管理器，需要在Kublet的特性门控处启用该特性。从Kubernetes 1.18 版本开始，这一特性默认启动。--feature-gates="...,TopologyManager=<true|false>"

        为了满足定制对齐方式需求，拓扑管理器提供了两种不同的方式：scope 和 policy。

          1）scope 定义了资源对齐的粒度（当前提供pod与 container 两种级别）。        2) policy 定义了对齐时实际使用的策略（当前提供best-effort、none、restricted、single-numa-node 等）。        a. 作用域

     正如上文所述，拓扑管理器提供以下两种不同的资源对齐粒度：container （默认)、pod。

       在 kubelet 启动时，可以使用 --topology-manager-scope 标志来配置其中任一粒度。        1）container作用域         默认使用的是 container 作用域，拓扑管理依次进行一系列的资源对齐， 即对每一个容器（包含在一个 Pod 里）单独计算对齐。拓扑管理会把单个容器任意地对齐到 NUMA 节点上。

        2）Pod作用域

         在启动 kubelet时，配置 --topology-manager-scope=pod ，即可对齐粒度为 pod 。 该作用域允许把一个 Pod 里的所有容器作为一个分组，分配到一个共同的 NUMA 节点，即拓扑管理会把一个 Pod 当成一个整体， 并且试图把整个 Pod（所有容器）分配到一个单个的 NUMA 节点或者一个共同的 NUMA 节点集。下例说明了拓扑管理器在不同的场景下使用的对齐方式：        1、所有容器可以被分配到一个单一的 NUMA 节点        2、所有容器可以被分配到一个共享的 NUMA 节点集合        整个 Pod 请求的某种资源总量通过 request/limit公式计算， 因此，对某一种资源而言，该总量等于以下数值中的最大值：       1、 所有应用容器请求之和        2、Init容器请求的最大值        对于延迟敏感或者 IPC 高吞吐量工作负载，在配置Pod 作用域及 single-numa-node 拓扑管理策略时，可以把一个 Pod 里的所有容器都放到单一 NUMA 节点， 使得该 Pod 消除了 NUMA 之间的通信开销。        在 single-numa-node 策略下，只有当可能的分配方案中存在合适的 NUMA 节点集时，Kubelet才会准入该Pod。如下述的示例：        1、节点集只包含单个 NUMA 节点时，Pod 就会被准入        2、节点集包含多个 NUMA 节点时，Pod 会被拒绝

        简而言之，拓扑管理器首先计算出 NUMA 节点集，然后使用拓扑管理策略来测试该集合， 从而决定拒绝或者接受 Pod。

        b. 策略

        拓扑管理支持四种分配策略，在 Kubelet 启动时，可以通过 Kubelet命令行 --topology-manager-policy 设置。当前支持的策略有四种：

• none (默认)

• best-effort

• restricted

• single-numa-node

        1）none        这是默认策略，不执行任何拓扑对齐。        2）best-effort

        对于 Guaranteed 类Pod 中的每个容器，配置 best-effort 拓扑管理策略的 kubelet 将调用每个Hint Provider以确定资源可用性。使用此信息，拓扑管理器存储该容器的首选亲和性NUMA 节点。如果亲和性不是首选，则拓扑管理器将存储该亲和性，并且无论如何都将 Pod 接纳到该节点，之后Hint Provider在进行资源分配决策时使用该信息。

        3）restricted 策略        对于 Guaranteed 类 Pod 中的每个容器， 配置了 restricted 拓扑管理策略的 Kubelet 调用每个Hint Provider以确定其资源可用性。使用此信息，拓扑管理器存储该容器的首选亲和性 NUMA 节点。如果亲和性不是首选，则拓扑管理器将从节点中拒绝此 Pod 。这将导致 Pod 处于 Terminated 状态。Pod调度失败，Kubernetes 调度器不会尝试重新调度该 Pod，建议使用 ReplicaSet 或者 Deployment部署 Pod。如果 Pod 被允许运行在某节点，则 Hint Provider 可以在做出资源分配决策时使用此信息。        4）single-numa-node 策略        对于 Guaranteed 类 Pod 中的每个容器， 配置了 single-numa-node 拓扑管理策略的 Kubelet 调用每个Hint Provider以确定其资源可用性。使用此信息，拓扑管理器确定单一 NUMA 节点亲和性是否可能。如果是这样，则拓扑管理器将存储此信息，然后Hint Provider可以在做出资源分配决定时使用此信息。如果不满足，则拓扑管理器将拒绝该Pod ，这将导致 Pod 处于 Terminated 状态。一旦 Pod 处于 Terminated 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。

        2.2 Pod配置

        注意：关于Pod三种QoS介绍，后续会详细说明。        1) 没有指定资源 requests 或
limits，该 Pod 以 BestEffort QoS 运行。spec:
containers:
- name: nginx
  image: nginx       2) requests少于 limits，该 Pod 以 Burstable QoS 运行。spec:
containers:
- name: nginx
  image: nginx
  resources:
    limits:
      memory: "200Mi"
    requests:
      memory: "100Mi"        针对上述 Pod，如果选择的策略是 none 以外的任何其他策略，拓扑管理器都会评估这些 Pod 的资源使用。拓扑管理器会调用每个Hint Provider，获得拓扑结果。当策略为 static，且Hint Provider为 CPU时，不进行分配记录。    3）requests 值等于 limits 值 ，因此以 Guaranteed QoS 运行。spec:
containers:
- name: nginx
  image: nginx
  resources:
    limits:
      memory: "200Mi"
      cpu: "2"
      example.com/device: "1"
    requests:
      memory: "200Mi"
      cpu: "2"
      example.com/device: "1"    4）未指定 CPU 和内存请求，Pod 以 BestEffort QoS 类运行。spec:
containers:
- name: nginx
  image: nginx
  resources:
    limits:
      example.com/deviceA: "1"
      example.com/deviceB: "1"
    requests:
      example.com/deviceA: "1"
      example.com/deviceB: "1"        总结如下：        1、对于 Guaranteed 类的Pod, 如果CPU 请求数为整数，CPU 管理器策略为static 时，将返回与 CPU 请求有关的提示， 而设备管理器将返回有关所请求设备的提示。对于 Guaranteed 类的 CPU 请求可共享的 Pod（非整数CPU），CPU 管理器策略为static 时，将返回默认的拓扑提示，因为没有排他性的 CPU 请求，而设备管理器则针对所请求的设备返回有关提示。在上述两种 Guaranteed Pod 的情况中，CPU 管理器策略为none时， 返回默认的拓扑提示。        2、对于 BestEffort Pod，由于没有 CPU 请求，CPU 管理器策略为static时， 将发送默认提示， 而设备管理器将为每个请求的设备发送提示。基于此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，为 Hint Provider在进行资源分配时使用。

        2.3 示范说明

        例如，在图2中，包含2个NUMA节点，2个Socket（每个Socket具有4个CPU，2个GPU和2个NIC），CPU 0-3、GPU 0和NIC 0在Socket 0中，其属于NUMA 0节点，CPU 4-7、GPU 1和NIC 1在Socket 1中，其属于NUMA 1节点。

        只有相应外设实现Device Plugin接口，且Kubelet启用Device Manager时，Pod才能够从设备插件提供的可用资源中请求设备资源（例如intel.com/sriov、nvidia.com/gpu等）。比如已经完成Device Plugin接口的Nvidia GPU设备插件和Intel SRIOV网络设备插件。        假设Kubelet对于CPUManager启用了static策略，并且gpu-vendor.com和nic-vendor.com的设备插件已实现Device Plugin接口，则下面的Pod配置可以使用拓扑管理器以运行其选定的策略：spec:
  containers:
  - name: numa-aligned-container
    image: alpine
    resources:
        limits:
            cpu: 2
            memory: 200Mi
            gpu-vendor.com/gpu: 1
            nic-vendor.com/nic: 1        按照图1资源情况，资源对齐结果如下所示：{cpu: {0, 1}, gpu: 0, nic: 0}
{cpu: {0, 2}, gpu: 0, nic: 0}
{cpu: {0, 3}, gpu: 0, nic: 0}
{cpu: {1, 2}, gpu: 0, nic: 0}
{cpu: {1, 3}, gpu: 0, nic: 0}
{cpu: {2, 3}, gpu: 0, nic: 0}

{cpu: {4, 5}, gpu: 1, nic: 1}
{cpu: {4, 6}, gpu: 1, nic: 1}
{cpu: {4, 7}, gpu: 1, nic: 1}
{cpu: {5, 6}, gpu: 1, nic: 1}
{cpu: {5, 7}, gpu: 1, nic: 1}
{cpu: {6, 7}, gpu: 1, nic: 1}        注意：（再次申明）如果某个Pod被拓扑管理器拒绝，它的状态将为Terminated，并带有一个Pod准入错误和“TopologyAffinityError的原因说明。一旦Pod处于该状态，Kubernetes调度程序将不会尝试重新调度。        未完，待续.

三、参考资料

1. https://kubernetes.io/blog/2020/04/01/kubernetes-1-18-feature-topoloy-manager-beta/

2.https://kubernetes.io/docs/tasks/administer-cluster/topology-manager/

3.https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/

4.https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/topology-manager.md

作者简介

zouyee，一般性码农，CNCF大使，CoreDNS维护者，Kubernetes、KNative社区成员。专注于基础架构，Cloud Native布道师，敏捷实践者，21年打算点亮Dapr、operator、gRPC等社区天赋。

 往期 · 精选 

点个“在看”让我知道你在看哟